Comments
-
Thanks for this.. I just started getting alerts as well until I added the exclusion
-
I'm a little confused about the SSO bit. Can you elaborate? I have the Sonicwall configuration tool installed which I believe is related to the SSO agent. That doesn't have to do with SSLVPN I don't think...
-
Yes, I am using a UTM appliance (NSA 3600) and domain users are connecting via NetExtender with their domain credentials (not local Sonicwall user accounts). I don't know what authentication partitioning is but I'm using LDAP + Local Users for User Authentication settings. See my new screenshot for details showing that…
-
I actually tried that but got an error (I forget what it was), then when setting it to our correct domain name, I was able to get in. I can try it again just to be sure though.. To be clear, user's are signing in with their AD credentials with Sonicwall MFA.
-
It actually doesn't defeat the purpose of SSLVPN at all. The idea is pretty simple. I only want employees accessing the company network on company managed devices, not personal ones. Imagine someone downloaded NetExtender on their home PC with Windows 7 and tons of malware and having that connect on our company network.…
-
I am talking about restricting access for the SSLVPN users to only the computers I give them. For example, say I give Bob access to SSLVPN access and I give him a computer with NetExtender installed. Now he can get remote access, which is good. However, what if Bob installs NetExtender on his home PC and then remotes in on…
-
Hey BWC, let me also ask you... with SSLVPN, "Tunnel All Mode" would be the most secure right? The alternative exposes some corporate network info to the user's home network doesn't it?
-
Got it, thanks. We do have a CA server so I guess I can try using that. Other than the self-signed cert pop-up, are there any other security concerns there?
-
Thanks for the response and that makes sense. However, in my situation, I'd be using Sonicwall NetExtender to connect to an IP address over port 4433 and then the user would RDP into their on-prem workstation. We wouldn't be using the web browser. I was also contemplating registering a domain name for that IP (or maybe…
-
Lets say I wanted to use a public domain name instead of an IP address to connect with NetExtender. Would the cert need to be for that domain name?
-
Correction - I meant to say I have a NSA 3600
-
Gotchya. Yeah I have been reading up on it. I'll look into blocking that after hours since I don't want to mess up people's Chrome sessions right now. I assume blocking that will cause Chrome to revert to using regular TCP then so blocking it should be a non-issue.
-
You suggest blocking UDP 443? I just checked and we actually have a few rules explicitly enabling it from PC VLAN to WAN for Google QUICK. I don't know anything about the QUICK protocol so I'll have to do some reading. Does a Sonicwall KB article mention the suggestion of blocking it?
-
Hey again Larry, could you link me to the documentation you used? I have been reading through the Sonicwall KB and, so far, I can only find the links listed below. They seem to cover most of the DPI-SSL configuration, but I'm trying to do a testing phase right now and I'm a little confused about how to specify just one PC…
-
Hey Larry, thanks for your reply. Let me ask you, do you also have DPI-SSL enabled on those interfaces? If not, then the IDS/IPS system and its reporting are very limited since the majority of traffic will be encrypted. Then, if you do have DPI-SSL enabled, do you ever run into issues with sites breaking? I'm just asking…